home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20000114-20000217
/
000168_news@columbia.edu _Thu Jan 27 21:28:16 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA25412
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 27 Jan 2000 21:28:16 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA02370
for kermit.misc@watsun.cc.columbia.edu; Thu, 27 Jan 2000 21:01:40 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Case Study #10: Atomic File Movement
Date: 28 Jan 2000 02:01:39 GMT
Organization: Columbia University
Message-ID: <86qta3$2a0$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <gSF8krj$2SXn@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
: A "friendly amendment." While the Kermit protocol, and TCP, do an
: acceptable job of confirming stages of work are completed, those techniques
: do not remove ambiguity. Frank correctly states "somewhat immune." Old
: packets whose sequence numbers have wrapped to the proper current value,
: badly garbled ones with apparently legit contents (CRC checks are hardly
: perfect), and packets delivered by mistake to the wrong session, are three
: serious concerns for protocol designers because they confuse the normal
: stage by stage confirmations. TCP uses three way handshakes, extra steps
: to extend sequence numbers in some circumstances, and pseudo headers, to
: help reduce false indications. Kermit does a pretty good job too, but not
: to the extent that TCP goes.
: The two hill army problem remains when one gets serious about comms.
: As stated, there is no certainty in the exchange, only approximation to it.
:
I meant to get back to this earlier, (so as not to leave an unsettling
impression with readers who don't study these topics) but better late than
never.
I believe most of Joe's observations pertain more to TCP and IP than to
Kermit:
. Old packets whose sequence numbers have wrapped. This can happen in
TCP/IP because it's a worldwide packet-switched network. A TCP packet
(encapsulated within an IP packet) can be stuck in the network for
minutes, hours, days, or weeks, and then show up after the sequence
number space has recycled one or more times, and then it can cause
trouble unless there is a higher (than TCP) level of checking. But
Kermit connections are either point-to-point in fact, or in effect, so
packets don't lurk in odd crannies of the world and reappear at a later
time -- at least not late enough to cause confusion about packet
numbers. Why? Because (in the non-streaming case) every Kermit packet
must be acknowledged. The window can't be larger than half the
sequence number space, and it can't advance until the oldest packet in
the window is acknowledged. This technique, called "sliding windows
with selective retransmission", is more conservative and robust than
the technique TCP uses in preventing packet sequence number ambiguity.
. Packets are delivered by mistake to the wrong session. Can't happen in
Kermit because there is only one session.
. Packets can be garbled to look like other packets. Yes, this can
happen in any communictions protocol with some calculable probability.
But let's look at the consequence in the context of atomic file
movement. First, it is possible (but highly unlikely) that a data
packet can be corrupted in such a way that its CRC will still be
correct, thus allowing bad data into a file (but only if the packet
sequence number, length, and other controls remain valid). Of course
this can happen in any communications protocol; there is a whole
literature on the subject. But what about the progress of the protocol
itself? Each possible happenstance and its consequences can be
examined in turn. For example, an ACK can turn into a NAK with the
same sequence number. No harm is done. A NAK can turn into an ACK for
the same packet. Again, no harm is done (because the seemingly ACK'd
packet will missing at the receiver, and this will cause the transfer
to fail eventually.) An ACK is turned into something besides an ACK or
NAK: then we have an illegal packet type and the transfer fails. An
ACK is turned into an ACK with a different sequence number; if it's an
"old" sequence number it is ignored and no harm is done; if it's a
"new" one, the sender will catch the error ("You ACK'd a packet I didn't
send"). And so on.
In other words, I think it is safe to say that the chances are practically
negligible that a Kermit transfer will appear to succeed when it failed.
Except perhaps for possible data corruption, which all protocols are subject
to; as noted in the literature, the number of errors that a CRC will not
catch is very small, and the probability that exactly such an error will
occur, out of all the kinds of errors that can occur, is much smaller still.
And in fact, in 20 years of experience with Kermit transfers, I can't recall
a single confirmed report of the protocol reporting success when the
transfer failed.
- Frank